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Preparamos una nueva 
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Experimentos 
para ciudades virtuales 


(parte 1) 


A pesar de tener como 
tema de sección la 
| puesta en práctica de 
| alguna de las ideas 
"surgidas de las 
animaciones 


presentadas en 


el número 


anterior, las 


medievales publiados en los números O y 1. ace ya algunos nú- 


meros. se concibió 


¿Sería posible realizar alguna película con algún 


la idea de crear la 
arquitectura básica 


dragón volando sobre la ciudad o con un barco de las ciudades y 
castillos de cada 
acercándose a su puerto? una de las razas que pueblan nuestro 


mundillo medieval. Por esta razón, de- 


2 Rendermanía 


sempolvar la versión 2.0 de «Castlib» 
era un buen punto de partida para defi- 
nir el estilo arquitectónico de las ciu- 
dades de los humanos. Como quizá re- 
cordéis, esta librería fue escrita para 
«POV 3.0» y estaba compuesta por ob- 
jetos no demasiado complejos, cuyo 
propósito consistía en ayudarnos a ge- 
nerar castillos y ciudades medievales. 
Los modelos de «Castlib 2.0» son muy 
sencillos, pero, aunque Carecen prácti- 
camente de detalles, pueden servir para 
renderizar escenas bastante resultonas 
si se genera un número suficientemente 
alto de objetos utilizando bucles Hwbhi- 
le (siempre que se sitúe la cámara auna 
distancia adecuada). 

Por otrú lado, y dado que desde ha- 
ce algunos números venimos dedican- 
do artículos al tema de la animación, 
fue inevitable preguntarse si sería po- 
sible emplear a «Castlib» para realizar 
alguna película. 


La lentitud de Castlib 2,0 

Con esta idea en mente, se comenzó 
a revisar la librería para adaptarla a la 
versión 3.1 de «POV», Así, después de 
haber hecho algunos ajustes menores, 
se lanzaron un par de pruebas ignoran- 
do el montón de warnings con que pro- 
testó «POV» por no haber añadido los 
nuevos punto y coma de rigor en los si- 
tios precisos (ver el último número de 
Rendermanía). El resultado fue desa- 
lentador. No por las escenas en sí, sino 
por la lentitud de los renders (a pesar 
del nuevo Pentium Il a 333 MHz). ¿Por 
qué? Sin duda, más de un detractor de 
«POV» pensará que, simplemente, 
«POV>» es lento. Pero esta respuesta 
debe ser descartada, ya que aquí se han 
generado escenas más complejas en 
mucho menos tiempo. Los problemas 


había que buscarlos en los defectos de 
diseño de la propia «Castlib 2.0». Estos 
defectos son: 

e «Castlib 2.0» emplea objetos ge- 
nerados con el propio lenguaje escéni- 
co de «POV». Estos objetos son, en su 
mayoría, muy simples, pero aun así no 


se renderizan tan rápidamente como 
los objetos poligonales. 

e Muchos de los objetos de la vieja 
librería se superponen espacialmente 
cuando se están construyendo casas y 
otros modelos. Este es el caso de las vi- 
gas de madera de los paneles básicos, 
po ejemplo. Tanto las casas como los 
castillos de «Castlib» se construyen 
empleando simples paneles rectangu- 
lares que incorporan ventanas, vigas y 
otros objetos. Al colocar estos paneles 
para levantar una casa, muchas de las 
vigas se superponen. ¿Qué que importa 
eso? Pues mucho en tiempo de render. 
En efecto, gran parte del tiempo de cál- 
culo de cualquier trazador de rayos se 
emplea en calcular la intersección de 
los rayos lanzados con las superficies 
de los objetos. Pues bien, este proceso 
puede ralentizarse si dos o más objetos 
presentan superficies superpuestas. 

e Los objetos que emplean CSG. 
Las operaciones CSG son la base de la 
construcción de modelos con el len- 
guaje escénico de «POV», por lo que 


no puede decirse rez ente que su uso 
sea un error. Ocurre tan sólo que cual- 
quier objeto poligonal se renderizará 
mucho más rápidamente que un objeto 
generado con CSG en «POV». ¿Por 
qué? Porque en este último caso, ade- 
más de renderizar, «POV» tiene que 
calcular las operaciones CSG con las 
que se crean los objetos. 

Aparte de estos problemas principa- 
les, el empleo de «Castlib 2.0» presen- 
taba algunos inconvenientes secunda- 
rios más; crear una ciudad de 200 o 
300 casas precisa bastante memoria y, 
si deseábamos incluir también habi- 
tantes, no había ninguna forma de evi- 
tar la superposición con otros objetos 
(salvo reservando algunas zonas pre- 
viamente, por supuesto). 


Nuevos métodos 
para una vieja idea 

Teniendo todo esto en cuenta se optó 
por crear una nueva versión de 
«Castlib» que evitase en lo posible los 
defectos de la vieja librería. Después de 
realizar algunas pruebas y de descartar 
algunos diseños, se llegaron a las si- 
guientes conclusiones: 

e La idea de crear estructuras com- 
plejas como casas o torres a partir de 
otros objetos mucho más simples se- 
guía siendo válida. Combinando estos 


objetos básicos se pueden crear 
muchas estructuras diferentes, 
aunque inevitablemente habrá 
una gran similitud entre todas. 
Sin embargo, esto siempre será 
mejor que crear sólo 4 o 5 mode- 
los complejos de casas para cons- 
truir un pueblo. 


Para crear las nuevas piezas 
básicas (los paneles, tejados, 
ventanas, vigas. etc.) había que 
utilizar un modelador poligonal. 
Más tarde las piezas podrían ex- 
portarse a «POV» utilizando la 
sentencia mesh. Esto implicaba, 
al menos, dos ventajas. En pri- 
mer lugar, los objetos poligona- 
les que se almacenan con mesh 
ocupan muy poco espacio ya 
que, a partir de la segunda copia, 
«POV>» emplea matrices para re- 
ferenciar al objeto original en lu- 
gar de duplicar la memoria. Y en 
segundo lugar, las mallas de polí- 
gonos (almacenadas con las sen- 
tencias triangle y smooth_trian- 
gle de «POV») ahorran mucho 
tiempo de cálculo. 

o ¿Por qué no aprovechar las 
nuevas macros de «POV>» y los 
arrays? Empleando macros es 
factible realizar rutinas que gene- 
ren casas e incluso ciudades ente- 
ras por nosotros. En «Castlib 
2.0» se “dectaraban” 40 0 50 ca- 
sas construyéndolas a partir de 
las piezas básicas. Para «Castlib 2.5», 
sin embargo, podíamos escribir macros 
que generasen las casas aleatoriamente 
y que colocasen escaleras o puentes si- 
guiendo criterios más dependientes del 
terreno. En cuanto a los arrays, podía- 
mos emplearlos para marcar las zonas 
libres y poder situar así a los personajes. 


Taller Virtual 


Casas definidas de la antigua librería. 


Utilizar «Rhinoceros» 
Aceptando estas premisas, el si- 
guiente paso fue elegir el modetador 
adecuado para crear las piezas básicas. 
Aunque esto podía haberse hecho utili- 
zando cualquier buen modelador poli- 
gonal. la elección finalmente recayó en 
Rhinoceros, por varias razones. La 


primera porque las piezas bási- 
cas que debían crearse eran de 
muy fácil construcción utilizan- 
do las fiables operaciones CSG 
de «Rhino». y la segunda porque 
«Rhinoceros» tiene exportación 
directa a «POV>» y genera archi- 
vos donde las mallas se almace- 
nan con las sentencias de este 
raytracer. Además. la opción de 
«Rhinoceros» de conversión de 
objetos nurb a mallas poligona- 
les, que antes no estaba demasia- 
do bien terminada, funciona 
ahora perfectamente. 

El primer paso fue definir la es- 
cala de trabajo. Los lectores que 
hayan echado un vistazo a los 
personajes de nuestro mundo 
medieval sabrán que estamos 
utilizando una escala en la que 
100 unidades equivale a un me- 
tro. Por tanto, lo primero fue 
adaptar el tamaño del grid y del 
snap a esa escala asignando un 
tamaño de un decímetro a cada 
intersección de la retícula. Así. 
un panel de 3 metros de alto por 
uno de largo ocupa 30*10 cua- 
drículas que equivalen a 
300*100 unidades. 

El siguiente paso fue crear las 
piezas básicas de la librería. Es- 
tas piezas son paneles rectangu- 
lares y triangulares que represen- 
tan a trozos de las paredes de las 
casas. Casi todas estas piezas se “ele- 
varon” a partir de curvas cerradas utili- 
zando la opción “Extrude Planar Cur- 
ve” ya explicada en el artículo anterior 
y con la que se crean formas sólidas. 
Posteriormente, algunos de estos pane- 
les fueron recortados empleando ope- 
raciones CSG para crear los huecos pa- 


ra las puertas y ventanas. Posterior- 
mente. las piezas terminadas se alma- 
cenaron como ficheros de «Rhino» y 
sólo cuando se tuvo un número lo sufi- 
cientemente elevado de ellas se pensó 
en exportarlas a «POV». 


La generación de mallas 

Las principales opciones de trabajo 
de «Rhino» están pensadas para la 
creación de superficies y sólidos nurb. 
Ántes de exportar nuestro trabajo al 
formato de «POV» o al de cualquier 
otro programa, hemos de convertir en 
mallas los objetos nurbs con los que 
hemos estado trabajando. Si no lo ha- 
cemos así, el mismo «Rhino» nos 
presentará la ventana de conversión 
antes de efectuar la grabación. Em- 
plear adecuadamente las opciones de 
esta ventana tiene una importancia ca- 
pital ya que si nos descuidamos pode- 
mos acabar con una malla de cientos 
o miles de polígonos para representar 
algo tan sencillo como un cubo. En 
versiones anteriores de «Rhinoceros», 
esta conversión era bastante proble- 
mática y Únicamente justificable en el 
caso de modelos de cierta compleji- 
dad como cabezas o armaduras. El 
problema era, en resumen, que los al- 
goritmos de «Rhino» tendían a produ- 
cir muchos más polígonos de los ne- 
cesarios. Afortunadamente, este 
problema está arreglado en la última 
versión del programa. 

Para convertir a poligonal un objeto 
nurb, habrá que seleccionarlo y pinchar 
en el icono “mesh from Nurbs Object” 
situado en la barra vertical de iconos, 
bajo el icono de las operaciones boole- 
anas. (Con este icono también se puede 
acceder a un menú emergente de ico- 
nos que permite crear objetos poligo- 


nales sencillos y realizar diversas ope- 
raciones con ellos). A continuación, se 
desplegará la ventana de conversión 
que puede aparecer en dos formatos 
distintos: “Simple Controls” y “Detai- 
led Controls”. En el primer caso, «Rhi- 
no» presentará una ventana muy sim- 
ple donde lo único que hay que hacer 
es mover un indi- 
cador para indi- 
car al programa 
el grado de deta- 
He de la malla a 
generar. Si se 
desplaza el indi- 
cador hacia “Fe- 
wer polygons”, 
«Rhino» intenta- 
rá crear una ma- 
lla con el menor 
número posible 
de caras. Hacer 
lo contrario He- 
vando la barra 
“More 
Polygons” tendrá 


hacia 


el efecto opuesto. 

Después de mover este indicador gene- 
raremos el objeto pulsando sobre OK. 
Aparecerán mensajes indicando los po- 
lígonos que se han generado y el objeto 
malla se superpondrá sobre el antiguo 
objeto-nurb. el cual seguirá selecciona- 
do. Si no nos convence el resultado po- 
demos retroceder con undo (Ctrl-Z) y 
volver a invocar la ventana de conver- 
sión pulsando el botón derecho del ra- 
tón sobre la ventana de trabajo (repeti- 
ción de acción anterior). 

Pero para tener un grado de control 
superior sobre la conversión será me- 
jor, sin duda, utilizar la ventana alter- 
nativa a la que accederemos pulsando 
sobre “Detailed controls”. En dicha 


ventana la conversión puede controlar- 
se de varias formas pero lo más usual 
es emplear el recuadro “max angle” en 
el que podemos especificar el ángulo 
máximo que permitirá «Rhino» entre 
las normales de la malla a crear. (Nota: 
la normal de un polígono se representa 
con una flecha que abandona a éste de 


manera perpendicular a su superficie). 


Al generar la malla, «Rhino» irá gene- 
rando triángulos subdividiendo las zo- 
nas nurb entre las que haya ángulos. 
Así. si entre las normales de dos trián- 
gulos adyacentes hay un ángulo supe- 
rior al especificado, el algoritmo creará 
un triángulo intermedio. Naturalmen- 
te, cuanto menor sea el valor que em- 
pleemos más densa será la malla resul- 
tante y viceversa. También suele ser 
muy conveniente marcar los recuadros 
“Refine” y Weld”. 

Ahora bien, la gran mayoría de las 
piezas a convertir en el presente caso 
eran formas planas y rectangulares 
(frecuentemente simples cubos estira- 


dos en algún eje) y por ello las opcio- 
nes mencionadas resultaban imprecisas 
y, a veces, inútiles. En estos casos lo 
que se hizo fue marcar la opción “Sim- 
ple Planes”. Esta opción genera mallas 
muy optimizadas para formas simples, 
llegando en ocasiones a crear objetos 


La variable lados determina 
los lados visibles. 


de tan sólo 12 polígonos en el 
caso de algunos paneles o vigas. 
Recordad, no obstante, que esta 
opción es bastante inútil en los 
casos de objetos curvados (co- 
mo las vigas de soporte latera- 
les de las casas o las piezas de 
recorte para las ventanas de pie- 
dra, por ejemplo). 


Filosofía en la construcción 
de la librería 

El criterio principal al construir las 
piezas de «Castlib 2.5» ha sido el de 
conseguir la máxima velocidad posible 
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durante el render. Por ello, en ocasio- 
nes se han almacenado piezas que están 
realmente duplicadas varias veces den- 
tro de un mismo objeto. Este es el caso 
de los maderos de la puerta o de los ba- 
rrotes del balcón. Hubiera sido muy 
sencillo almacenar un solo madero o un 


solo barrote y generar desde «POV» el 
resto de las piezas necesarias para 


montar el objeto. Sin embargo. estas 
piezas tenían tan pocos polígonos que 
se prefirió no obrar de esta manera y 
ganar así algo de velocidad, por poca 
que fuese. Hay que decir, no obstante, 


que no todas las piezas están almace- 
nadas de una manera Óptima O si- 
guiendo siempre el mismo criterio. 
Así. por ejemplo, aunque la gran ma- 
yoría de las piezas se han almacenado 
con el borde pegado al eje Y (verde) y 
descansando sobre el eje X (rojo), éste 
no ha sido siempre el caso, algunos 
paneles frontales se han almacenado 
desplazados porque en muchos casos 
se esperaba que quedarían en las po- 
siciones originales de desplazamiento 
al ser renderizados. 

En cuanto a los propios ficheros que 
forman la librería, hay que decir que 
en el momento de escribir estas líneas 
su organización es un poco caótica. El 
motivo es que «Castlib 2.5» es, toda- 
vía, una versión beta. Aunque prácti- 
camente todas las piezas básicas están 
ya almacenadas en los ficheros .inc, 
aún faltan varias de las macros princi- 
pales que nos permiti- 
rán generar las esce- 
nas. Y es que «Castlib 
2.5» es una librería 
en parte de objetos y 
en parte de macros 
(ver el número ante- 
rior). Los objetos son 
las piezas básicas de 
construcción, pero és- 
tas no se montarán “a 
mano” sino dando pa- 
rámetros a las macros 
suministradas. 

Pero por ahora centré- 
monos en los objetos. Éstos están al- 
macenados en una serie de archivos de 
los cuales el principal es Castlibl.inc. 
La estructura de este fichero es muy 
simple, estando todas las piezas agru- 
padas por tamaños. Primero tenemos 
los trozos de pared de 3x1 metros, lue- 


go los de 3x2, etc. 
Generalmente, den- 
tro de estos aparta- 
dos se definen pri- 
vigas, 
luego los trozos de 


mero las 
pared desnudos y 
después los trozos 
de paredes monta- 
das, es decir, con las 
puertas, ventanas y 
vigas definidas pre- 
viamente. Se ha pro- 
curado que los nombres de estas piezas 
sean tan explícitos como fuese posible 
y por ello tenemos identificadores co- 
mo “panelR3x1_puertal0”, que signi- 
fica que la pieza es un panel de pared 
rectangular (R) que incluye la puerta de 
tipo 10, o como “barandilla_escale- 
ra_3x3”, que se refiere a la barandilla 
de una escalera de 3 metros de largo 
(en Z) y 3 metros de subida (en Y). Por 
ahora, la lectura de Castlibl es bastante 
fastidiosa ya que los objetos importa- 
dos están intercalados con las defini- 
ciones de las piezas “completas”. Ade- 
más, muchos objetos-mesh demasiado 
grandes se han trasladado a ficheros 
más pequeños que son cargados desde 
castlibl (para no hacer imposible la 
lectura). Pero realmente la organiza- 
ción de estos archivos de piezas no es 
importante porque no esperamos que 
nadie se ponga a estudiar las definicio- 
nes de unas piezas que, por otra parte, 
pueden ser cambiadas. Lo importante 
es la manera en que podemos utilizar 
estas piezas empleando las macros. 


Lo que se pretende hacer 
Utilizar las piezas básicas de ta li- 

brería para montar casas a mano es bas- 

tante tedioso, incluso haciéndolo des- 


de «Rhino». Es mucho más atractiva la 
idea de organizar las piezas según su ti- 
po y escribir desde «POV» macros que 
puedan generar casas cuya forma, esti- 
lo y dimensiones dependan de los pará- 
metros suministrados a dichas macros. 
Los propósitos de esta idea son múlti- 
ples. Se experimentará con la potencia 
de las nuevas sentencias de «POV» y 
nos ahorraremos bastante trabajo al 
montar las escenas. En el momento de 
escribir estas líneas faltan aún muchas 
cosas por probar, pero esperamos que 
la versión definitiva de la presente ver- 
sión pueda hacer las siguientes cosas: 
O Las casas y estructuras se monta- 
rán en una serie de estructuras situadas 
a diversas alturas y conectadas entre sí 
con escaleras. Las casas marcarán el 
espacio ocupado dentro de estas super- 
ficies gracias a un array que se em- 
pleará como mapa de las calles. Este 
mapa servirá para determinar las zonas 
despejadas donde pueden situarse ha- 
bitantes. De esta forma. podríamos pre- 
parar una batalla en las calles de una 
ciudad, utilizando una macro que bus- 
case las zonas libres del array para los 
combatientes. Por ahora no se contem- 
pla que este array-mapa tenga tres di- 
mensiones (lo que serviría para mapear 


Comprobación de los tamaños de varlos objetos de «Castlib 2.5». 


criaturas como dra- 
gones o grifos vo- 
lando a baja altura 
sin miedo a que pu- 
diesen superponerse 
sobre una casa O to- 
rre demasiado alta). 
e Con muy pocos 
cambios, la librería 
de funciones debe- 
ría poder ser utiliza- 
da para generar es- 
cenas empleando 
piezas básicas diferentes. De esta ma- 
nera, y con muy poco esfuerzo, podría- 
mos crear escenas de poblados. forta- 
lezas orcas o incluso Evormigueros. 

o Resulta fácil situar habitantes 
aprovechando la colocación de ciertas 
piezas de la librería. Una de ellas, por 
ejemplo, es un sencillo balcón que 
puede colocarse en los pisos donde se 
ha permitido que haya puertas que dan 
a la calle. Dando a un personaje las 
mismas coordenadas de dicho balcón 
y sumándole una pequeña traslación 
resulta fácil colocarlo apoyado en éste 
y mirando a la calle, sin que importe 
en qué parte de la ciudad esté. Y lo 
mismo cabe decir de las ventanas, es- 
calinatas y otras piezas. 

O La velocidad del render debería ser 
sensiblemente superior a la conseguida 
con «Castlib 2.0». Las pruebas realiza- 
das hasta ahora indican que esto será 
así a pesar de que no se han Hevado a 
cabo aún con pueblos grandes. Hay que 
decir que aunque las nuevas piezas evi- 
tan muchas superposiciones, éstas no 
han podido ser erradicadas totalmente. 
También debería producirse un ahorro 
de memoria de cálculo, aunque aún no 
se han podido realizar comparaciones 


definitivas en este punto. 


ns 
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Las macros de la librería 

Las macros definitivas de «Castlib 
2.5» todavía se encuentran lejos de es- 
tar acabadas en el momento de escribir 
estas líneas. Sin embargo, no se espera 
que la estructura básica de las macros 
ya escritas sufra cambios de importan- 


El sencillo balcón de Castlib 2.5 


cia, como tampoco es de esperar que 
esto suceda con los arrays empleados 
para definir la estructura de los datos 
empleados. Básicamente las escenas se 
construirán empleando una única ma- 
cro a la que llamaremos Trazacalles (y 
que todavía no está escrita). El cometi- 
do de esta macro será el de crear casas 
dentro de un área definida por unas co- 


8 Rendermanía 


ordenadas. Para ello la macro llamará a 
otra macro denominada Make House 
(que sí está escrita al 90%) y ésta a su 
vez llamará a otras como CreaMuro y 
MakeTejado (que están terminadas al 
90% y al 10%, respectivamente). Co- 
mo ya imaginaréis por los nombres, 
MakeHouse crea las 
casas individuales de 
la escena empleando 
para ello los valores de 
parámetros para el es- 
tilo, las dimensiones, 
el número de pisos y 
los lados visibles. 
¿Qué significa esto de 
los tados visibles? 
Bien, simplificando, 
todas las casas de la li- 
brería tienen única- 
mente cuatro paredes 
principales (las estruc- 
turas laterales y col- 
gantes pueden enten- 
derse como otras casas 
de menor tamaño pe- 
gadas o colgadas a la 
principal). Estas pare- 
des forman planos que 
guardan siempre 90 
grados con las paredes 
laterales y 180 con la 
pared opuesta. Esto 
significa que, por su- 
puesto, siempre vere- 
mos, únicamente, dos de los lados de 
cualquier casa. Los lados opuestos no 
serán visibles y entonces, ¿para qué ge- 
nerarlos a ellos y a sus objetos corres- 
pondientes? Por ahora. en las pruebas, 
la variable “lados” que se encarga de 
este detalle es pasada a Makehouse 
manualmente. Sin embargo, próxima- 
mente su valor será puesto desde Tra- 


zacalles. dependiendo de la posición 
que hayamos asignado a la cámara. 

En cuanto a CreaMuro, su cometido 
es bien simple: debe generar un muro 
de una longitud determinada utilizan- 
do la lista de paneles de la serie que se 
le indica en uno de los parámetros. Una 
serie es, en nuestra librería, una lista de 
objetos-panel definida en el array “se- 
rie_paneles”. Por otra parte, el array 
“lista_estilos” guarda una lista de se- 
ries que configuran un estilo. Al llamar 
varias veces a CreaMuro para levantar 
la casa, MakeHouse puede pasarle di- 
ferentes series como parámetro en cada 
ocasión. Se puede, pues, definir una se- 
rie para el primer piso, otra para los su- 
periores, etc. (Tened en cuenta que, por 
ahora, hay dos construcciones básicas: 
la rústica y la de piedra). 


Un posible problema 

Un detalle que preocupa es el de la 
expansión del código de las macros. 
Para crear cada casa, «POV» debe ex- 
pandir el código correspondiente con 
cada llamada a las macros empleadas. 
Esto plantea la pregunta de si desecha 
«POV» el código expandido una vez lo 
está compilando. Si esto es así (lo que 
es de suponer) no hay motivo para pre- 
ocuparse. pero si sucede lo contrario. 
el consumo de memoria podría dispa- 
rarse en casos como el presente. En fin, 
será una de las cosas que comprobare- 
mos en el próximo numero. 
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-  Rhinoceros: operaciones (SG 
- yproblemas con objetos 


Desde su primera aparición en el número 11 de 


Rendermanía, «Rhinoceros» ha ido ganando rápidamente 
adeptos entre los lectores. Esto es comprensible ya 
que el programa de McNeel y Asociados es potente, 
cómodo, rápido y fácil de manejar. Sin embargo, los 
numerosos cambios e innovaciones que sus 
creadores han ido introduciendo con las sucesivas 
betas de este modelador pueden acabar 
despistando al lector, y por ello analizaremos la 
filosofía de trabajo de la última beta publicada en 
la dirección www.rhino3d.com. 
nlos artículos de los ¿ an puede acabar cambiando la filo- 
números 11 y 16 ¿ sofía de trabajo de muchos de los 
dedicados a «Rhi- E usuarios de «Rhinoceros». 
noceros» hablába- : 


mos de este progra- E Cambios, 
ma como un ¿ modificaciones y problemas 


modelador de splines cuyo sistema de : «Rhino» es, de momento, nuestro 
trabajo se basaba sobre todo en el di- E modelador favorito y ello se debe a las 
bujo de curvas que luego podían ser : siguientes razones: 

“elevadas” para obtener superficies. ; O Se trabaja con mucha rapidez: la 
Esta idea sigue siendo válida pero la A interfaz de manejo permite realizar di- 


inclusión de nuevas opciones de mode- ¿ ferentes secuencias de acciones com- 
tado o la mejora de otras que ya existí- ¿  plejas con muy pocos clicks de ratón. 


lo ad o 


Con «Rhino», operaciones que se eter- 
nizarían en programas antiguos como 
«3D Studio» o «Imagine» se llevan a 
cabo en muy poco tiempo. 

e Se trabaja con curvas spline y las 
opciones de elevación de estas curvas 
(para crear superficies) son muy po- 
tentes. Esto quiere decir que se pueden 
crear numerosas formas orgánicas con 
cierta facilidad (al menos, más fácil- 
mente que con los antiguos modelado- 
res poligonales). 

e Las operaciones booleanas pare- 
cen muy fiables. En las pruebas reali- 
zadas por la redacción de la revista, no 
se encontró nunca con ningún mensaje 
que indicara que la operación ordenada 
no podía realizarse. 

e «Rhinoceros» contempla la expor- 
tación de modelos para muchos otros 
programas, entre los que cabe destacar 
a «3D Studio», «Lightwave», «Áuto- 
CAD» y «POV». 
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ce estar en la reorganización de los ¡co- 


nos del programa y en el cambio gráfi- 
co de casi todos ellos. 

En esta versión la distribución de los 
iconos parece mas lógica y su repre- 


sentación gráfica explica mejor las 
operaciones relacionadas, pero en la 
documentación visible en la ayuda se 
siguen empleando los gráficos ya des- 


cartados de los iconos antiguos. En 
¿cuanto a los iconos que no funcionan, 
¿ esto podría deberse a la premura con 
que se realizaron los cambios antes del 


¿lanzamiento definitivo que —se presu- 
y me-— está al caer. En fin, es de esperar 
3 que estas pegas desaparezcan en la 
próxima versión del programa. 


Comandos de teclado 
En «Rhinoceros» se puede trabajar 


de tres formas diferentes. Se pue- 
Pero no todo son ventajas, aun- den ordenar las diversas acciones 
que se rumorea que la versión de- pulsando en la opción 
finitiva de «Rhinoce- adecuada del menú o 
ros» será lanzada en sobre el icono corres- 
octubre o noviem- pondiente, o bien te- 
bre, lo cierto es que 


la beta analizada en 


cleando directamen- 
te el comando 
estas páginas (que asociado. Áun- 
expira el 31 de que lo mas rá- 
octubre) presenta pido suele ser 


algunas pegas. Es- utilizar los 


to puede parecer ex- iconos, hay 

ocasiones 
donde puede 
resultar más 
rápido escribir 
un comando en la consola (la 
fila que sigue a “Command”, 
sobre la línea horizontal de 
iconos). La verdad es que, de 


forma automática, cada vez 


traño en un producto cuya pri- 
mera beta apareció hace ya 
dos años, pero no por ello es 
menos cierto que hay iconos 
que no funcionan, órdenes que 
no son reconocidas y una do- 
cumentación (en la ayuda) 
que va muy por detrás de los 
cambios y de las nuevas opcio- 
nes del programa. La explica- que se pulsa un icono o se eli- 


ción de estos problemas pare- ge una opción del menú, el 


comando de teclado asocia- 
do aparece en la consola, 
con lo que poco a poco y sin 
darnos cuenta, ¡remos 
aprendiendo órdenes escri- 
tas. Además, algunas órde- 
nes necesitan parámetros es- 
critos por teclado. Pero al 
final, utilizar más o menos la 
consola dependerá de la for- 
ma de trabajo de cada uno, 
La redación suele escribir 
las órdenes para manipular 
el grid y algún que otro co- 
mando como Csec (utilizado 
para crear secciones a partir 
de curvas perfil dibujadas 
previamente). Veamos algu- 
nos de estos comandos: 

e “gridsize”: en «Rhino- 
ceros», como en tantos otros 
modeladores, las ventanas de 
trabajo exhiben una malla de 
líneas llamada grid o retícula cuyas in- 
tersecciones se utilizan para facilitar el 
dibujo. Por ejemplo, cuando estemos 
dibujando curvas, los extremos de és- 
tas se ajustarán a las intersecciones de 
la retícula. Y, de la misma manera, el 
grid resultará vital en otras operaciones 
como el desplazamiento, la rotación y 
el escalado de objetos. Pues bien, el ta- 
maño de las intersecciones del grid 
puede ser establecido con el comando 
gridsize al que deberá seguir un valor 
indicando el tamaño. (Escribid gridsize 
y pulsad enter. «Rhino» mostrará el ta- 
maño del grid actual. Meted el nuevo 
valor y pulsad enter). 

e “grid”: este comando activa o de- 
sactiva el grid. 

e “snap”: aunque el grid aparezca en 
las ventanas de trabajo. esto no quiere 
decir que lo estemos utilizando. Para 


...pero antes de editar los puntos de la copa 
habremos de convertirla en un objeto poligonal. 


hacer que los comandos de dibujo o 
edición se ajusten a las intersecciones 
del grid, teclead el comando snap que 
activa o desactiva el empleo del grid. 

o “snapsize”: aunque las intersec- 
ciones del grid tengan un tamaño esta- 
blecido, el ajuste en las operaciones de 
dibujo o edición puede no coincidir 
con sus dimensiones (aunque normal- 
mente será así). Para determinar las 
unidades de distancia que hay entre 
cada paso tendremos que emplear el 
comando “snapsize”. 

e “gridsections”: este comando se 
utiliza para especificar el número de in- 
tersecciones del grid (y por tanto el ta- 
maño de la malla). 

e “gridthick”: cada cierto número de 
líneas, la malla de la retícula tiene una 
línea de un color más claro. La utilidad 
de dicha línea es la de ayudarnos a me- 


dir las distancias en las diver- 
sas operaciones. Utilizando 
“eridthick” podremos especi- 
ficar cada cuántas líneas nor- 
males queremos que aparez- 
ca una línea clara. 

e “ortho”: a veces puede in- 
teresarnos no emplear el 
grid, pero sí que el punto a 
dibujar se mantenga a lo lar- 
go de una línea dada o que el 
objeto a rotar sólo pueda ha- 
cerlo un número x de grados 
en cada paso. Con este co- 
mando las operaciones se 
harán de x en x grados. 

e “orthoangle”: con este co- 
mando especificaremos el 
número de grados que se em- 
pleará en cada paso si la op- 
ción ortho está activada (el 
valor por defecto es 90). 


Organización 
y uso de los iconos 
Normalmente, se emplean, pre- 
ferentemente, los iconos a las Órdenes 
de teclado o a las opciones del menu. 
Éstos están divididos en dos áreas. En 
la barra horizontal de iconos se puede 
acceder a las opciones de control de las 
ventanas de trabajo. De izquierda a de- 
recha y a partir del icono de la mano se 
encuentran las operaciones de despla- 
zamiento, rotación, zoom manual, zo- 
om de ventana, centrado de escena y 
centrado de objetos seleccionados. 
También se encuentran aquí otros 1co- 
nos de uso frecuente como el que per- 
mite elegir la vista para la ventana en 
curso (el del cochecito), el de selección 
(“All”) —que se emplea para puntos, 
curvas, superficies y objetos—, el de vi- 
sibilidad (“Hide”), el de sombreado (la 
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as 


bola gris) y el de opciones. En cuanto a 
los iconos de creación y edición de 
puntos, curvas, superficies y sólidos, 
están localizados en la doble columna 
de iconos del lado izquierdo de la pan- 
talla. En muchos casos, al mantener 
pulsado el botón izquierdo del ratón 
con el cursor sobre uno de estos iconos. 
puede verse cómo aparece una subven- 
tana emergente de iconos relacionados 
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ado el botón derecho. (Nota: en algu- 
nos Casos, apretar el botón izquierdo o 
el derecho del ratón tendrá un resultado 
diferente al mencionado. Por ejemplo, 
en el caso del icono de sombreado, si 
empleamos el botón izquierdo, el ren- 
der de prueba se efectuará sólo sobre la 
ventana de trabajo en curso mientras 
que si utilizamos el botón derecho, el 
render se realizará en todas las venta- 


Modelado con «Rhino» por Agnisola Philippe. 


con el icono pulsado, el cual también 
aparecerá en la subventana. A veces, 
incluso, puede aparecer una segunda 
ventana emergente si repetimos la ope- 
ración sobre un icono de la ventana an- 
terior, pero esto no es muy frecuente. 
Por otro lado, si en lugar de mantener 
apretado el botón lo pulsamos rápida- 
mente, el submenú no aparecerá. En lu- 
gar de esto se activará la orden corres- 
pondiente si hemos utilizado el botón 
izquierdo del ratón, o se desactivará (si 
es que esto es posible) si hemos emple- 
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nas). Naturalmente, esto no quiere de- 
cir que todos los iconos principales co- 
necten con submenús. Muchos de estos 
iconos (de la doble columna principal) 
activan órdenes directamente, ya que se 
supone que van a ser empleados con 
frecuencia. Es este modo de trabajo el 
que determina la velocidad de trabajo 
del programa (unto con algunos trucos 
más como el hacer que se repita el últi- 
mo comando impartido si pulsamos 
con el botón derecho en la zona de las 
ventanas de trabajo). 


El trabajo con las curvas 

A continuación señalaremos los ico- 
nos de trabajo más empleados. Nor- 
malmente, hay que empezar por crear 
las curvas que luego serán empleadas 
como secciones a elevar o como paths 
(rutas) de elevación. Para crear estas 
curvas utilizaremos los iconos de crea- 
ción de líneas rectas, curvas, círculos, 
elipses, arcos, rectángulos y polígonos. 
Todos estos iconos (situados en la parte 
superior de la columna principal) per- 
miten acceder a menús emergentes de 
iconos, aunque normalmente nos bas- 
tará con emplear (utilizando la pulsa- 
ción rápida) las opciones atadas a los 
iconos principales. 

Una vez dibujadas las curvas pode- 
mos necesitar alterarlas, y para ello 
emplearemos los iconos de edición y 
control de puntos. Veamos cómo fun- 
cionan. Se dibuja una curva cualquiera 
y posteriormente se pincha sobre ella 
para seleccionarla (con lo que se vol- 
verá amarilla). Después habrá que pin- 
char sobre el icono situado bajo el lla- 
mado “Trim”. Esto provocará la 
aparición de los puntos de edición de 
la curva a los que se puede pinchar y 
arrastrar individualmente. Además, po- 
dremos seleccionar varios puntos si 
pinchamos sobre ellos mientras mante- 
nemos pulsada la tecla de shift (tam- 
bién podemos crear una ventana de se- 
lección si mantenemos apretado el 
botón izquierdo del ratón mientras 
arrastramos el cursor). De esta manera. 
podremos mover conjuntamente los 
puntos seleccionados (amarillos) o uti- 
lizar sobre ellos las operaciones accesi- 
bles a través del icono de transforma- 
ciones (transform), aunque no tiene 
sentido aplicar muchas de estas opera- 
ciones sobre los puntos de edición. 


aj 


o 


a 


to 


Otra posibilidad consiste en 
modificar la curva alterando 
sus puntos de control, los 
cuales están fuera de la curva 
y pueden ser editados utili- 
zando el icono “Point edi- 
ting”, situado al lado del an- 
terior y que permite acceder 
a una ventana emergente. 


Generar superficies 

Una vez creadas las curvas 
y paths necesarios podemos 
hacer uso de las opciones de 
elevación accesibles a través 
de la ventana emergente del 
icono “Surface”. Dichas op- 
ciones han sufrido algunos 
cambios desde que las estu- 
diamos en un artículo del nú- 
mero 16 de Rendermanía. 
Aquí resumimos el propósito 
de las más empleadas: 

o “Surface from planar 
Curves”: con esta opción se 
puede llegar a generar una superficie a 
partir de una curva plana. Para lograr 
esta acción basta con seleccionar la 
curva y pinchar el icono. 

o “Extrude Straight”: permite acce- 
der a un nuevo submenú de extrusio- 
nes de las cuales la más empleada es 
la propia “extrude straight” que sirve 
para elevar una curva a lo largo de un 
path recto (basta con seleccionar la 
curva, pinchar en el icono y luego des- 
plazar el cursor para determinar la lon- 
gitud de la extrusión). También es bas- 
tante utilizado el icono “extrude along 
path”, con el que efectuaremos la ex- 
trusión a lo largo de una curva que ha- 
bremos dibujado previamente (aunque 
la curva no se adapta al path, como ha- 
ce “Sweep along 1 rail”). 


e “Loft”: con esta opción crearemos 
una forma en tres dimensiones utili- 
zando una serie de curvas que el pro- 
grama interpretará como secciones de 
la forma a crear. Primero hay que di- 
bujar las curvas y luego. tras pinchar la 
opción, «Rhinoceros» pedirá que se 
pulsen las curvas en orden. (También 
habrá que indicar al programa si la for- 
ma gira a lo largo del path, e igual su- 
cede en la siguiente opción). Al termi- 
nar, se pulsará Enter y la forma será 
generada. Las curvas no tienen por qué 
tener la misma forma ni tamaño y pue- 
den estar orientadas en distintas direc- 
ciones. Esta opción es muy utilizada 
para crear partes orgánicas como bra- 
zos, torsos, etc., dibujando previamen- 
te secciones de los mismos. 


La opción pipe es ideai para construir tuberías. 


Comprobación de la fiabilidad de las operaciones CSG. 


o “Sweep along 1 rail”: el 
programa «Rhinoceros» pe- 
dirá que seleccionemos el 
patch (rail) a través del cual 
ha de efectuarse la elevación, 
y después tendremos que pul- 
sar en orden sobre las curvas- 
sección que deberían haber 
sido dibujadas a lo largo del 
path. Posteriormente se pin- 
chará sobre el icono y se pul- 
sará Fl para ver un ejemplo 
de las formas que pueden lo- 
grarse con esta opción. 

o “Revolve”: esta es la opción 
que se utiliza para generar su- 
perficies de revolución. Para 
ello tendremos que pulsar so- 
bre ella y posteriormente ha- 
cer lo propio sobre la curva a 
“revolucionar” en la ventana 
“Front”. A continuación se 
indicará el eje de revolución 
en la misma ventana y se pul- 
sará la tecla Enter. 

La verdad es que todas estas opcio- 
nes no sólo sirven para crear superfi- 
cies. En casi todos los casos es posible 
especificar si se quiere generar una for- 
ma cerrada o no. Utilizando “Extrude 
Straight”, por ejemplo, basta con tecle- 
ar “cap” (tapa) y pulsar Enter cuando 
«Rhinoceros» pida la distancia de la 
extrusión. Este comando de teclado ac- 
tiva O desactiva la colocación de tapas 
en la forma a elevar. En el caso de 
“Loft”, en cambio, habrá que marcar la 
opción “closed loft” dentro de la venta- 
na de opciones del comando. Es impor- 
tante entender que al activar la opción 
de colocación de tapas, «Rhinoceros» 
creará un sólido y no una superficie. 
Algo que tendrá su importancia con las 
operaciones CSG. 


Emplearemos la opción 
“extrude planar Curve” con la 
curva seleccionada. 


Sólidos y operaciones CSG 
Existe un conjunto de opciones que 
en versiones anteriores de «Rhinoce- 
ros» tenían una importancia menor, 
pero que van a ganar puntos a partir de 
la presente versión. Se trata de las ope- 
raciones CSG (geometría de construc- 
ción de sólidos). Estas operaciones 
constituyen la base del modelado con 
«POV» y también están implementa- 
das en programas como «3D Studio» 
o «Imagine». En estos últimos, no obs- 
tante, estas operaciones no son dema- 
siado fiables. ¿Por qué? Pues porque 
estos modeladores trabajan con obje- 
tos compuestos por polígonos y, según 
parece, los algoritmos de CSG que tra- 
bajan con polígonos no son fiables al 
100%. En «POV», en cambio, los ob- 
jetos creados por el lenguaje de este 
raytracer no son poligonales sino crea- 
dos mediante fórmulas, y los algorit- 
mos CSG que operan sobre este tipo 
de objetos son mucho más fiables que 
sus equivalentes poligonales. ¿Y qué 
sucede en el caso de «Rhinoceros»? 
Dicho programa trabaja con diferentes 
tipos de objetos: curvas, superficies, 
polysuperficies, sólidos y mallas (ob- 
jetos poligonales). Las operaciones 
CSG de «Rhinoceros» funcionan sólo 
con superficies, polysuperficies y só- 
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Posteriormente intentaremos 
que el resultado se curve 
alrededor de la esfera. 


lidos, y son sorprendentemente fiables. 
El problema radica en que si converti- 
mos un objeto de este tipo en uno poli- 
gonal no se podrá seguir efectuando 
operaciones CSG con él, 

Para comprobar la teoría haremos al- 
gunos experimentos. Pulsad sobre el 
icono solid (el del cubo) para hacer 
aparecer el submenú de creación de ob- 
jetos sólidos de «Rhinoceros». Aquí 
podemos crear una serie de objetos cu- 
yo volumen interno está “lleno” (de ahí 
lo de “sólidos”). Pulsad sobre el icono 
de la esfera y cread una. Posteriormen- 
te repetid la operación, pero esta vez 
con el icono del cubo y situando el 
nuevo objeto de manera que se super- 
ponga parcialmente con la esfera. Aho- 
ra pulsad sobre el icono “Solid Tools” 
(situado junto al anterior) para hacer 
aparecer su menú emergente. Es aquí 
donde se ordenan las operaciones CSG 
(y otras relacionadas con éstas). Pulsad 
sobre el icono llamado “Boolean diffe- 
rence”, que se emplea para hacer res- 
tas CSG (las operaciones CSG también 
suelen ser llamadas operaciones boole- 
anas). Hecho esto, «Rhinoceros» nos 
pedirá que seleccionemos una superfi- 
cie o polysuperficie. Pinchad sobre la 
esfera. «Rhinoceros» mostrará un nue- 
vo mensaje pidiendo que seleccione- 


s»» Y para conseguirlo lo mejor es 
restar un par de esferas a la 
forma extruída. 


mos la superficie O polysuperficie que 
se restará del primer objeto. Pulsad so- 
bre el cubo y observad el resultado, El 
cubo ha desaparecido y también parte 
de la esfera. El objeto visible es el re- 
sultado de restar a la esfera el volumen 
espacial del cubo. Para visualizar me- 


E jor el resultado habrá que utilizar el 


icono de sombreado. De esa manera se 
puede comprobar que el objeto resul- 
tante sigue siendo un sólido, ya que 
«Rhinoceros» ha creado “tapas” en la 
zona restada. A todos los efectos ha si- 
do como si los objetos hubiesen sido 
realmente cuerpos sólidos verdaderos 
y el volumen del cubo se hubiera resta- 
do del de la esfera. Naturalmente, si 
hubiésemos restado la esfera del cubo, 
el resultado hubiese sido distinto. 

Y ¿cómo funciona la operación de 
intersección CSG? Pulsando Ctrl-Z pa- 
ra ordenar el undo de «Rhinoceros» y 
luego pinchando en el icono “Boolean 
Intersection” del menú emergente an- 
terior. Hecho esto habrá que volver a 
seleccionar los dos objetos y compro- 
bar que esta vez el resultado ha sido un 
objeto que por su forma y volumen 
equivale al volumen interior que com- 
partían los dos objetos iniciales. 

Una vez más hay que utilizar el undo 
y probar, en esta ocasión, el icono *Bo- 


“ye 


olean Union”. Los dos objetos se han 
convertido en uno solo (las partes inter- 
nas de ambos objetos se han borrado). 
La unión, la sustracción y la intersec- 
ción son todas las operaciones CSG que 
implementa «Rhinoceros» («POV» aña- 
de una extra: merge). Con ellas es posi- 
ble crear formas cuya construcción es 
algo más complicada utilizando superfi- 
cies. Normalmente, emplearemos estas 
operaciones con sólidos, así que regre- 
semos al submenú del icono de sólidos. 
AMí existen otros tres iconos muy inte- 
resantes. Uno de ellos es “Pipe”, que es 
sumamente útil para modelar tubos re- 
torcidos. Antes de utilizarlo hay que di- 
bujar una curva abierta para que sirva 
como patch. Posteriormente habrá que 
pinchar sobre “Pipe” y seleccionar la 
curva. «Rhinoceros» se sitiará en uno de 
los extremos de la curva permitiendo 
definir el tamaño de un círculo que ser- 
virá como sección inicial de la extru- 


sión. Una vez definida esta primera sec- - 


ción, «Rhinoceros» situará la edición en 
el otro extremo del path con el objetivo 
de crear la sección final cuyo tamaño no 
tiene por qué ser el mismo que el de la 
primera. Al hacer click el resultado de- 
berá ser un tubo cerrado (otro sólido). 
El siguiente icono de interés en el 
submenú de sólidos es “Extrude Planar 
Curve”. Para estudiar su funciona- 
miento tendremos que crear una curva 
cerrada, seleccionarla, y pulsar el ico- 
no. Esto genera una extrusión de la cur- 
va a lo largo de una línea recta, tal y co- 
mo hace “Extrude straight”. La 
diferencia está en que los objetos gene- 
rados mediante “Extrude Planar Cur- 
ve” son sólidos, es decir, este coman- 
do crea tapas por defecto en los 
extremos de la nueva forma. En cuanto 
al siguiente icono, “Extrude Surface”, 


Modelado con «Rhino» por Jerome Desvignes. 


funciona como el anterior y produce 
los mismos resultados, aunque necesita 
una superficie como punto de partida y 
no una Curva. 


Operaciones CSG 
con superficies 

La forma en que «Rhinoceros» 
efectúa operaciones booleanas con su- 
perficies es realmente curiosa, además 
de útil. Supongamos que tenemos una 
superficie en forma de tubo abierto y 
una pequeña esfera que corta parcial- 
mente el centro del tubo. En muchos 
modeladores, si pidiéramos al progra- 
ma que restara esta esfera del tubo, la 
operación (en el supuesto de que el 
programa permitiera hacerla) daría 
como resultado un agujero en el tubo. 
«Rhinoceros», en cambio, dará otro 
resultado: obtendremos un abomba- 
miento del tubo hacia adentro en la 
zona de resta. Esto equivale en reali- 
dad a restar el espacio de la esfera del 
espacio del tubo y a poner luego una 
tapa (con la forma de la “piel” de la 
esfera) en el agujero. 

Pero aún hay más. Podemos con- 
vertir la superficie resultante en un só- 
lido fácilmente. Para ello habrá que 
hacer aparecer el icono emergente de 
“Solid Tools”, pulsar sobre el icono 
“Cap Planar Holes” y luego seleccio- 


nar el tubo del ejemplo anterior y pul- 
sar Enter. Esto pondrá dos tapas al tu- 
bo, con lo que «Rhino» entenderá que 
tenemos un sólido, un cilindro, en lu- 
gar de una superficie, lo cual tendrá su 
efecto en las próximas operaciones 
CSG que se efectúen sobre el objeto. 
Si ahora. por ejemplo. creásemos otro 
cilindro algo más largo que el primero 
y lo colocásemos cortando el centro 
de aquel e hiciéramos una nueva resta 
booleana, el resultado sería un tubo de 
un determinado grosor (que seguiría 
siendo un sólido). 

Ahora conviene tomar nota de un 
par de detalles. Primero. las tapas só- 
lo pueden colocarse sobre superficies 
que tengan agujeros planos, como en 
el caso del primer ejemplo. Siguiendo 
con el ejemplo anterior, supongamos 
que pinchamos sobre el icono “Ex- 
tract Surface” del menú emergente 
“Solid Tools”. «Rhinoceros» pedirá 
que seleccionemos las superficies a 
extraer del sólido. Habrá que pinchar 
sobre las líneas de la resta de la esfera 
para seleccionar esa superficie y pul- 
sar Enter. Podremos extraer la super- 
ficie seleccionada del cilindro que 
ahora volverá a ser una superficie. Pe- 
ro, como el nuevo agujero no es pla- 
no. no podremos volver a cerrarlo con 
“Cap Planar Holes”. 
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Utilizando operaciones booleanas 
es fácil crear objetos muy complejos 
con bastante facilidad, si, claro está, 
los algoritmos utilizados por el pro- 
grama son fiables, y este es el caso 
particular de «Rhinoceros». 


¿Por qué no puede 
hacerse esto? 

Parece que el mayor problema al que 
suelen enfrentarse los usuarios de 
«Rhinoceros» es el de determinar 


Informe Especial 


momento el tipo de objeto con el que 
se está trabajando. 

Un ejemplo de esto son, como ya se 
ha dicho. las operaciones booleanas. 
Éstas no funcionan con los objetos po- 
ligonales. Sin embargo, no hay más re- 
medio que convertir los objetos-spline 
en objetos poligonales para exportarlos 
a Otros programas. Por esta razón será 
conveniente guardar también el fiche- 
ro 3dm (el formato de «Rhino») con 
los objetos-spline. por si más adelante 


Modelado con «Rhino» por Rex Sutton. 


cuándo se puede llevar a cabo o no una 
operación determinada sobre un objeto. 
Ello se debe a que en «Rhinoceros» 
existen diferentes tipos de objetos y a 
que se puede obtener una misma forma 
empleando diferentes caminos. Sin em- 
bargo, como todas las operaciones no 
funcionan con todos los tipos de obje- 
tos, habrá que tener presente en todo 
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hay que hacer modificaciones. (No es 
posible convertir un objeto-poligonal 
en un objeto-spline). 

Además, tampoco se pueden editar 
los puntos de todos los tipos de obje- 
tos. En efecto, la edición de puntos só- 
lo funciona con curvas, superficies y 
mallas poligonales, no sobre polysu- 
perficies. Aquí el problema está en de- 


terminar cuándo el objeto es una poly- 
superficie o no. 

Si se crea una esfera con el icono del 
menú de sólidos. se podrán editar sus 
puntos. Pero si se crea un cubo con el 


icono de la misma ventana, «Rhinoce- 
ros» responderá que no puede editar los 
puntos de una polysuperficie. 

Por otra parte, si se crea un tubo 
sin tapas con la opción “Extrude 
Straight”, se podrán editar sus puntos. 
Pero si se le añaden tapas (Cap Planar 
Holes), el objeto pasará a convertirse 
en una polysuperficie y no se podrán 
editar los puntos (aunque se pueden 
volver a editar si se le quitan las ta- 
pas). Ahora supongamos que efectua- 
mos una operación booleana de resta 
sobre el tubo sin tapas. En este caso el 
objeto pasará a convertirse en una 
polysuperficie y tampoco se podrán 
editar sus puntos. Otro ejemplo más. 
Como ya hemos dicho, es posible edi- 
tar los puntos de una esfera. Sin em- 
bargo, si le practicamos cualquier ope- 
ración booleana, ésta pasará también 
a convertirse en una polysuperficie, 
con lo que tendremos que decir adiós 
a la edición de puntos. Resumiendo: 

o Parece que efectuar una operación 
CSG sobre un objeto convierte a éste 
en una polysuperficie y lo mismo suce- 
de si se le ponen tapas. Por tanto, si se 
quiere editar sus puntos habrá que con- 
vertirlo en un objeto poligonal. 

e «Rhinoceros» no efectúa operacio- 
nes CSG sobre objetos poligonales. 

o No es posible llegar a convertir un 
objeto poligonal a un objeto definido 
por curvas spline. 

Estos tres puntos implican que habrá 
que tener sumo cuidado al pasar de un 
tipo de objeto a Otro, porque una vez 
realizado no habrá vuelta atrás. 


he 
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El Foro del Lector 


Nota importante. Podéis remitirnos vuestros trabajos o consultas, bien por carta a la dirección que 
figura en el sumario de POmanía, o vía e-mail a rendermania.pemania O hobbypress.es 


El poder del (SG 


El título del foro de este número 
se debe a las magníficas 
escenas realizadas por José L. 
García Fuertes, quien 
demuestra lo que puede dar de 
sí la filosofía de modelado de 
«POV» basada en la geometría 
de construcción de sólidos. Pero 
también se podría haber basado 
dicho título en las 
preciosas escenas de 
interiores de Antonio 
Casado o en los 
modelos de Jesús 
Sáez Redondo o los de Eduardo 
Oliden. ¿Y qué decir de la 
animación de Borja Morales? Lo 
cierto es que todos los autores 
merecen una mención especial 


por una u otra razón. 


Jose L. García Fuertes modela, aplica texturas 
y genera las escenas utilizando únicamente 
«POV». Tan sólo esto ya sería destacable de por 


sí. puesto que cada vez hay más pov-usuarios 


que se apoyan en modeladores externos para 
crear sus modelos, pero es que. además, los modelos de este autor 
son, por su diseño y acabado, fabulosos. El carguero estelar es pro- 
bablemente la mejor nave espacial enviada nunca por un lector. Y el 
submarino y el galeón suponen dos grandes aportaciones al mundo 
medieval virtual que estamos construyendo. Y todos estos modelos 
han sido construidos enteramente desde «POV» Quizá se eche de 
menos algo de porquería en el casco del carguero y una escala mucho 
más pequeña para la textura de la madera en el submarino. Por lo 
demás. tus diseños son originales y los motlelos tienen un gran nivel 
de detalle y un excelente acabado. Gracias por enviarnos los fuentes 


de estos modelos y por tu idea para la portada temática de la ciudad. 
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es un antiguo lector que 
ya ha enviado varios trabajos, pero hasta ahora 
no había conseguido salir en Rendermanía. 
¿Enviaste estos trabajos directamente a Ren- 
dermanía? En fin, tus escenas (creadas con 
«MAX») tienen un asombroso nivel de realis- 
mo (conseguido gracias a la impecable aplica- 
ción de unas texturas más que bien elegidas y a 
una excelente iluminación). Lo único que no 
está a la altura de todo lo demás son los botes 
de champú del cuarto de baño, ya que se nota 
enseguida que éstos son sólo una textura. En 
cuanto a lo que dices sobre tus animaciones, 
recuerda nuestros dos números anteriores de- 
dicados a animaciones de gran tamaño. Natu- 
ralmente cuanto más pequeña sea una anima- 
ción más fácilmente podrá ser publicada, pero 
no hay una prohibición absoluta para las pelí- 
Culas de gran tamaño, aunque pueden tardar 
mucho más en aparecer. Enhorabuena por tus 
imágenes y también por tu página Web (cuya 


dirección hallaréis en el foro). 


del Lector 


Publicamos algunos trabajos de 


enviados en varias cartas. En- 
tre ellos hay que destacar a la simpáti- 
ca arañita. al coche y a su excelente 
R2-D2. Juan adjunta, además, los archivos de generación de algunas de 
estas imágenes creadas con «MAX». 


plantea algunas cuestiones sobre las “funciones” de «POV 3.0» y 
las primitivas de «Rhino». La nueva sentencia Hmacro de «POV 3.1» admite pa- 
rámetros y puede ser utilizada como una típica función de C (aunque siga tra- 
bajando expandiendo el código. como lo hacen las macros). En cuanto a la po- 
lémica polígonos vs primitivas de «POV», nos decantamos por utilizar los 
polígonos, aunque manipulándolos con el lenguaje de «POV» para crear es- 
tructuras mayores (empleando mesh). ¿Por qué razón? Porque normalmente 
importa más la velocidad que se gana con ellos que el espacio que se pierde con 
respecto a las primitivas de «POV». 


(3D Reality) ha reco- 
gido el guante lanzado por la hechicera 
de Juan Garraza Zurbano (publicada en 
Rendermanía 13) y nos envía una ani- 
mación creada con «3ds4» y «MAX». 
Ahora son los lectores quienes deben 
indicar con sus votos quién es el gana- 
dor. (Como recordaréis, las reglas para 


los combates entre personajes virtuales 


se indicaron en el foro del número 18 de ad o E gris 


Rendermanía). Para facilitar la votación, y ya que este es el primer duelo de 
este tipo que celebramos aquí, hemos incluido también la animación de Juan. 
En cuanto a la crítica solicitada en tu carta, lo mejor será olvidarla por una vez 
con el fin de no influir en la votación. Enhorabuena por tu robot creado con 
«Rhino» y «Metaballs» y por tu página Web. 


* 


A 


(Erfeamor de Monticom) es un pov- 
adepto bien conocido en estas páginas. Este mes publicamos un anti- 
guo trabajo suyo rescatado de un profundo pozo espacio-temporal. Se 
trata de un caza que Carlos ha utilizado para apalear al antiguo caza 
Hroki publicado en el número 3 de Rendermanía. Carlos ha incluido 
también un texto explicando el porqué del diseño del caza y algunos 
detalles más. También encontraréis aquí una demo creada por su her- 
mano César y que os servirá para conocer mejor a este seguidor del 
bando orco. Carlos nos envía también una sugerencia interesante: la de 
escribir historias que ayuden a perfilar mejor el mundo medieval de 
corte fantástico que estamos creando. Tomamos nota Carlos (aunque 
para ser justos ya hace tiempo que hay lectores que envían historias re- 


lativas a sus escenas o personajes, como Jose M. García Lorenzo). 


es un antiguo se- 
guidor de Render- 
manía que se con- 
fiesa gravemente 
afectado por el vi- 
rus infográfico. Es- 
te mes publicamos 
algunos de sus últi- 
mos trabajos con 
«MAX» entre los 
que hay que desta- 
car al arácnido 
guerrero de Stars- 


hip Troopers. 


Enhorabuena por 
tus excelentes mo- 
delos... y también 
un tirón de orejas 
por no enviar la 


malla del bichito. 


nos envía algunas sugerencias... y una peque- 
ña reprimenda por haber confundido su nombre en el número 21. Gracias 
por tus sugerencias sobre las utilidades de animación. Y sí, sería preferible 
que todas las animaciones enviadas no excediesen los 5 Megas comprimi- 


dos (pero esto no supone una prohibición absoluta para las demás). 


y - 


a A 


nos 
envía algunas 
imágenes de 
sus últimos tra- 
bajos creados 
empleando los 
programas de 
diseño «Meta- 
balls», «MAX» 


y «Rhinoceros». Jesús pide una opinión sobre ellos: se echa 


en falta una mayor resolución en los bitmaps del Spitfire (los 
bordes de los dibujos quedan borrosos) y quizá también algo 
más de detalle en el revólver. Por lo demás, los modelos, so- 
bre todo los del tanque y el Rex, son espectaculares y las tex- 


turas han sido bien elegidas. Esperamos tu próxima visita. 


A, 


El Foro del Lector 


sacho!l nos en- 


vía unas pov-escenas —una de ellas generada con 
el pov-ipas de Colefax— y solicita a los renderma- 
níacos que envíen ficheros de generación y ma- 
llas para que los más novatos puedan aprender. 
¡Excelente sugerencia! Por lo demás, tomamos 
nota de tu petición sobre lo del pov-ipas que ge- 
nera teclados para «POV» (busca en el subdirec- 


torio de Sonya, en Rendermanía). 


nos remite una 


serie de imágenes de 
su cuarto creadas con 
«MAX». También in- 
cluye un Mech mode- 
lado en «MAX» y 


convertido (gracias a 


«Rhinoceros») en un 
modelo articulable y 
renderizable desde 
«POV». Sin embargo. quizá lu más destacable sea la imagen arena ente- 
ramente creada con el programa «POV», donde este autor empleó los 


bucles de «POV 3.0» para crear un estadio con miles de butacas. En 


cuanto al tiempo de cálculo, otro día explicaremos algunos truquillos | 


para ganar tiempo en el render. | 


Oriol Bagan nos envía un brujo creado con «Ima- 
gine» para la próxima batalla medieval. Pero se te ha 
olvidado especificar el bando al que piensas apoyar. 
aunque hay que creer que eres un adepto de los no- 
muertos, ya que tu Warlock Jr. utiliza el esqueleto 
publicado en el número 9 de Rendermanía. En cuan- 
to a tus preguntas, tendrán que esperar al próximo ar- 
tículo que dediquemos a «Imagine», programa al que 


últimamente tenemos abandonado. 
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